🔧 wrench — Route smoke test passes even when the explicit route registration is removed.

Both adapters register a /{*rest} catch-all GET/POST at the end of RouterService::builder() (see cloudflare/src/app.rs:366-367). With this asserting only status != 404, removing the explicit .post("/auction", auction_handler) registration would still pass: the request falls through to post_fallback → handle_publisher_request → 5xx in CI (no origin), which is still != 404. The same false-positive applies to every smoke test in this file that asserts != 404 (verify_signature, admin/keys/, first_party/, /.well-known/trusted-server.json).

Suggested fix: Either introspect the router's registered routes directly, configure settings so the explicit handler returns a distinguishable status (e.g., 200) while the fallback returns 5xx, or inject a per-handler marker header to prove which handler actually ran.

This matches the prior reviewer's finding; PR #739 stacks a fix but is not merged into this branch.

🔧 wrench — Same wildcard-fallback false positive as the Cloudflare smoke tests.

Axum's router registers /{*rest} at lines 365-366 of src/app.rs. If the explicit .get("/first-party/proxy", fp_proxy_handler) registration were removed, this test still passes because the catch-all routes to get_fallback → handle_publisher_request, returning 5xx (still != 404).

Applies to every != 404 smoke test in this file. Same fix as the Cloudflare side.

🔧 wrench — Header presence check is too weak for a parity assertion.

The module-level contract is that critical header values match across adapters. This test only proves both adapters return some X-Geo-Info-Available header. If Axum returns true and Cloudflare returns false, the test still passes — exactly the kind of regression a parity suite must catch.

Suggested fix:

let axum_value = axum_headers.get("x-geo-info-available").and_then(|v| v.to_str().ok());
let cf_value = cf_headers.get("x-geo-info-available").and_then(|v| v.to_str().ok());
assert_eq!(
    axum_value, cf_value,
    "X-Geo-Info-Available value must match across adapters for {method} {path}"
);

Matches the prior reviewer's finding; PR #739 has the fix but is not merged here.

🔧 wrench — WWW-Authenticate parity is checked unevenly.

Axum side asserts presence only (line 219); Cloudflare side asserts the value starts with "Basic realm=" (line 228). A regression where both adapters return WWW-Authenticate but with different realms (e.g., Basic realm="admin" vs Basic realm="foo") or different schemes (Basic vs Bearer) would not be detected as a parity failure.

Suggested fix: Extract both values, assert axum_www_auth == cf_www_auth to enforce strict parity, OR explicitly document the non-parity dimensions in a comment.

Same issue at admin_deactivate_unauthenticated_parity (both sides presence-only).

🔧 wrench — Clippy gate runs against nothing.

crates/integration-tests is a publish = false package whose only targets are [[test]] binaries — no [lib], no [[bin]]. Without --all-targets, cargo clippy lints nothing meaningful, so tests/parity.rs and tests/integration.rs are not actually gated.

There is also a second issue: crates/integration-tests/Cargo.toml has no [lints] section. Because the crate is workspace-excluded (root [workspace].exclude), it does not inherit the workspace's unwrap_used = deny / panic = deny / print_stdout = warn lints even with --all-targets. Both gaps must be closed for the gate to mean anything.

Suggested fix:

run: cargo clippy --manifest-path crates/integration-tests/Cargo.toml --all-targets -- -D warnings

Additionally, add [lints] to crates/integration-tests/Cargo.toml (inline the workspace lints — lints.workspace = true may not resolve in an excluded crate).

The prior reviewer flagged the --all-targets half; the [lints] inheritance gap is additional.

🤔 thinking — MAX_GROWTH_FACTOR = 2.0 is too loose to catch real regressions.

Typical growth on the included html_processor.test.html is probably ≤1.05× (one injected script tag + a few URL rewrites). A regression that doubles script-tag injection or duplicates URL rewriting would land around 1.02-1.10× — still well under 2× — and this test would pass.

Suggested fix: Either tighten the bound to a value closer to observed real growth (e.g., 1.3×), or assert an absolute byte budget tied to the known script-tag length: assert!(output_size <= input_size + EXPECTED_INJECTION_BYTES + URL_REWRITE_DELTA_BYTES).

🤔 thinking — is_some parity is weaker than the parity goal.

If both adapters return JSON, this passes — even if the JSON bodies are completely different (one {"error":...}, one {"keys":[]}). The intent is parity of the discovery payload.

Suggested fix: Either compare top-level key sets (when both parse as JSON objects) or, if you control test settings, set up signing keys so both adapters return the success payload and assert payload equality. The current assertion only catches the case where one adapter returns JSON and the other returns HTML/text, which is unlikely to regress.

♻️ refactor — Add baselines that isolate fixed vs variable cost.

Current bench measures one input shape. Two additional inputs help regressions stay visible:

1. HTML with zero occurrences of origin_host — measures fixed pipeline overhead (rewriter init, lol_html parse).
2. HTML with rewrite-dense content (many origin-host URLs per KB) — measures rewriting cost per occurrence.

A bug that adds per-element overhead or duplicates rewriter passes shows up clearly in the second baseline; one that adds fixed init cost shows up in the first.

♻️ refactor — Helpers rebuild the full service per request.

Every axum_get / cf_get / axum_post / cf_post invocation calls AxumApp::routes() / CloudflareApp::routes(), which goes through the full settings + integration-registry boot path each time. With 8 tests × ~2 requests each, that's ~16+ router builds.

Not blocking now, but as the parity suite grows this will dominate test time. Consider a OnceCell<Arc<Router>> per adapter, scoped to the test binary.

⛏ nitpick — cf_post and axum_post are asymmetric.

axum_post unwraps three layers: .ready().await.expect().call().await.expect() then body collect.
cf_post (here) uses .oneshot() + into_bytes() synchronously.

The asymmetry isn't wrong, but reading the two paths side-by-side requires the reader to mentally translate. A pair of small helper traits or thin wrapper functions could symmetrize the call sites. Optional cleanup.